原帖 ｜ Jason ｜ 2026-06-26 16:20 ｜ 👍1 ｜ 阅读约1
做嵌入式软件开发，经常遇到 BUG，很多时候会遇到一些疑难杂症，可能要解决半个月以上，甚至一两个月。
今天教大家如何在大厂中提问和解决问题。当你遇到困难，需要大佬们协助的时候，你需要提供如下信息：
1.这个问题对整个项目来讲，影响程度如何，是否会卡量产，是不是死机重启类问题？如果是的话，这个问题定调就是不可谈判的，一定要拉资源进来解决掉的，包括人力资源、机器资源、外部资源。如果对整个项目来说不是很重要，就自行判断投入资源多少。
2.疑难杂症通常不是必现问题，所以要讲清楚：这个问题出现了几次，是测试多久出现，是否有复现手法。是本地随便拿机器就可以复现，还是产线大批量机器时候才会出现，还是售后用户使用出现的。这个信息非常重要，它决定了问题的复现概率。
3.这题是否怀疑和硬件有关，是否是特定机器容易出现？
4.如果产品有一供物料和二供物料，是否和某些物料差异相关？
5.这个问题解决的截止时间是什么时候，如果 deadline 之前解决不了，后果是什么？
6.问题的目前分析状态是什么，如果没找到根因，有没有 workround 的方法先上，不卡项目进展？
7.有没有劣化的方法，可以加速问题出现？因为只有容易复现的问题才好 debug。
上述问题描述的时候一定要细节。
然后再拉资源进来，比如抽调人手进来一起 debug，抽调上百台机器做一些劣化实验和 patch 验证，抽调硬件和产线人手定期点检测试机器看问题是否出现，出现了就导出 log 和 coredump 文件用于分析。
对于疑难杂症，影响因素往往是很多的，根因往往是抽丝剥茧，所以会有很多轮 DOE 设计验证实验，排除每一个影响因素。
这类问题必须每日更新进展，多开会议沟通，如果排查过程中排查到了其他模块，需要协助，态度要诚恳，不要吵架，不要吵架，不要吵架。重要的事说三遍。
注意事项：每次做实验的机器资源都很宝贵，该加的 debug log 一定要加完整，不要来来回回修改，不然复现后看 log 又发现某个地方漏加，浪费时间。
只有主导过这类 BUG 的解决，才是一个合格的高级嵌入式软件工程师。毕竟写代码在目前的 AI 加速下，壁垒正在降低。
必现类问题我们今天不做讨论，必现问题一般都很好解决。
相关笔记